Auftrag Contact UPDATE

Funktion

Der Auftrag dient dazu, die Daten eines bereits vorhandenen Contacts zu ändern.

Voraussetzungen

Der Auftrag kann nur durchgeführt werden, wenn der entsprechende Contact bereits existiert.

Besonderheiten

• Pflichtfelder müssen, auch wenn sie identisch bleiben, immer angegeben werden.

• Durch das Weglassen von Schlüsselwörtern bei Key/Value werden vorhandene Werte dieser Schlüsselwörter gelöscht.

• Wird ein Contact in einer Domain, auf der ein Dispute-Eintrag liegt, als "Holder" eingesetzt, so können mit einem UPDATE nicht alle Daten (Name, Organisation, Address, PostalCode, City und Country) geändert werden. In diesem Fall muss sich der RegAcc an Business Services wenden.

Verifikation

• Verifikationsinformationen werden einem vorhandenen Kontakt vom Typ PERSON oder ORG hinzugefügt, geändert oder wieder entfernt.
• Verifikationsinformationen können wieder gelöscht werden, indem bei einem Update keine Informationen dazu angeben werden.
  
  
• Ein Contact UPDATE-Auftrag löst einen neuen Verifizierungsvorgang für eine Domain aus, Syntax- und Vollständigkeits-Check und die Risikobewertung werden erneut durchgeführt.
• Die Contact-Handles des Domainbestands werden nicht systematisch gescannt, um für alle Domains eine Risikobewertung zu ermitteln. Davon ausgenommen sind anlassbezogene Überprüfung einzelner Bestandsdomains.
• Sollte eine anlassbezogene Überprüfung ein verdächtiges oder sehr hohes Risiko ergeben, muss eine Verifikation im Rahmen eines Domain-Auftrags durchgeführt werden, was eine Aktualisierung des Kontakts bedeutet.
• Verifikationsinformationen können auch bei einem Contact für eine Domain, für die ein DISPUTE-Verfahren läuft, angelegt oder geändert werden.

Typ des Contacts

Der Typ des Contacts kann mit einem UPDATE geändert werden:

• von PERSON auf ORG oder

• von ORG auf PERSON.

  Hinweis

  Bei Contacts, die bei einer Domain verwendet werden, auf die eine DISPUTE gesetzt ist, kann der Contact-Typ nicht geändert werden.

Auftragsparameter

Ein Auftrag setzt sich zusammen aus den Feldern des Datenobjekts "Contact" und weiteren Parametern, die nachfolgend beschrieben werden:

Häufige Fehler

Das im Auftrag angegebene Contact-Handle existiert nicht.

Beispiele

Beispielaufträge PERSON oder ORG

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Action: UPDATE
Version: 5.0
Handle: DENIC-1000002-MAX
Type: Person
Name: Max Mustermann
Organisation: DENIC eG
Address: Business Services
Address: Theodor-Stern-Kai 1
Address: The maximum number of
Address: address lines is five and
Address: one line may be 255 characters long.
PostalCode:    60596
City: Frankfurt am Main
CountryCode: DE
eMail: email-1@denic.de
eMail: email-2@denic.de
eMail: email-3@denic.de
eMail: email-4@denic.de
eMail: email-5@denic.de
eMail: email-6@denic.de
Phone: +49.6927235x290

[VerificationInformation]
VerifiedClaim: name
VerifiedClaim: address
VerificationResult: success
VerificationReference: ABC123/45GHT
VerificationTimestamp: 2023-11-11T15:36:21+02:00
VerificationEvidence: idcard
VerificationMethod: auth
TrustFramework: de_denic

[VerificationInformation]
VerifiedClaim: email
VerificationResult: failed
VerificationReference: 354546TZQ
VerificationTimestamp: 2023-10-04T12:22:19+02:00
VerificationEvidence: transaction_log
VerificationMethod: auth
TrustFramework: de_denic

1
2
3
4
5
6
7
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 
<registry-request xmlns="http://registry.denic.de/global/5.0" xmlns:contact="http://registry.denic.de/contact/5.0" xmlns:verification="http://registry.denic.de/verification/5.0">
  <contact:update>
    <contact:handle>DENIC-1000002-MAX</contact:handle>
    <contact:type>PERSON</contact:type>
    <contact:name>Max Mustermann</contact:name>

Die Struktur im XML-Dokument nach "contact:name" ist identisch zur Struktur eines Auftrags mit dem RRI-Protokoll 4.0 und kann von dort übernommen werden.

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    <verification:verificationInformation xsi:type="verification:verificationInformationType">
      <verification:verifiedClaims>
        <verification:claim>name</verification:claim>
        <verification:claim>address</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>success</verification:verificationResult>
      <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
      <verification:verificationTimestamp>2023-11-11T15:36:21+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>idcard</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_aml</verification:trustFramework>
    </verification:verificationInformation>
    <verification:verificationInformation xsi:type="verification:verificationInformationType">
      <verification:verifiedClaims>
        </verification:claim>email<verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>failed</verification:verificationResult>
      <verification:verificationReference>354546TZQ</verification:verificationReference>
      <verification:verificationTimestamp>2023-10-04T12:22:19+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>eidas</verification:trustFramework>
    </verification:verificationInformation>

Die Struktur im XML-Dokument vor "contact:update" ist identisch zur Struktur eines Auftrags mit dem RRI-Protokoll 4.0 und kann von dort übernommen werden.

31
32
33
  </contact:update>
  <ctid>cba-987654321</ctid>
</registry-request>

Datenobjekte PERSON oder ORG

Datenobjekt REQUEST